「実践 Amazon KMS」補遺
こんにちは、虎塚です。
今日は、以前イベントでお話しした「実践 Amazon KMS」の内容について、当日や後日いただいたご質問への回答をまとめたいと思います。
Q1. データキーを暗号化したマスターキーを覚えておく必要がある？
「データキーを暗号化するのに使ったマスターキーを覚えておかないと、データキーを復号できませんか？」というご質問がありました。
回答は「いいえ、覚えておく必要はありません」です。
詳細
KMSを使った暗号化では、概念的には次の2段階で鍵を使用します。
- 保護したい情報を、データキーで暗号化する
- 暗号化に使用したデータキーを、マスターキーで暗号化する
APIを利用した実際の操作としては、次のようになります。
- 暗号化されたデータキーと暗号化されていないデータキーを受け取る
- 暗号化されていないデータキーで、保護したい情報を暗号化する
- 暗号化されていないデータキーを削除する
- 暗号化されたデータキーだけを（復号にそなえて）保管する
1つ目のステップで、暗号化されたデータキーを取得するために用意されているAPIは、次の3種類です。
- データキーを生成して暗号化するAPI
- generate-data-key
- generate-data-key-withoud-plaintext
- データキー（のように小さなデータ）を暗号化するAPI
- encrypt
上記3種類のAPIは、引数に「データキーを暗号化するマスターキーのID」を指定して利用します。次の図は、generate-data-key APIの例です。
一方、データキーを復号するために、decryptというAPIが用意されています。このAPIの引数は、「暗号化されたデータキーそのもの」だけです。
上の図でいうと、CiphertextBlobが、暗号化されたデータキーを意味します。データキーを暗号化するのに使ったマスターキーは、指定する必要がありません。非対称のように感じるかもしれませんが、KMSの仕組み上、そうなっています。
（なお、発表時に、decrypt APIの説明で誤って「KeyId」を引数に渡している図を使ったために、こちらの質問をいただいたのではないかと思います。資料を訂正いたします。申し訳ありません）
補足
ちなみに、データキーを生成する際に、encryption-contextという任意のkey-value形式の文字列を引数に指定できます。この値はオプションです。
データキー生成時にこの値を使用した場合は、データキー復号時にも同じ文字列を指定しなければなりません。保管しておかなければならないのは、暗号化に使ったマスターキーでなく、こちらの値です。
Q2. RDSの暗号化に使った鍵をDisableしてもう一度Enableしたらどうなる？
「RDSの暗号化に使ったカスタマーマスターキーを無効化した場合、そのキーをもう一度有効化しても、暗号化対象のデータベースは正常に戻らないのか？」という質問を同僚から受けました。
回答は、「はい、戻りません！ そのDBインスタンスはもうダメです……」です。カスタマーマスターキーの無効化には、細心の注意を払ってください。
詳細
公式ドキュメントのとおり、DBインスタンスの暗号化に使用したキーを無効化するなどして、AWSからキーにアクセスできなくなった場合、たとえキーを後から再有効化しても、DBインスタンスは終了状態になります。DBインスタンスのバックアップからリストアするしかありません。
このような事態にそなえて、RDS暗号化にKMSを使うことにした場合は、DBの自動バックアップをかならず有効にしておきましょう。
Q3. カスタマーマスターキーを使う積極的な理由は？
上記のように、カスタマーマスターキーを誤って無効化することの危険性は、デフォルトマスターキーを使えば解決します。デフォルトマスターキーは、AWSによってあらかじめ用意されたマスターキーです。デフォルトマスターキーは、ユーザ操作によって無効化できません。
という話をしたところ、「それならデフォルトマスターキーではなく、カスタマーマスターキーを使う積極的な理由はあるの？（どんな時でもデフォルトマスターキーを使えばよいのでは？）」という質問を同僚から受けました。
回答は、「複数のキーポリシーを使い分けたい場合は、カスタマーマスターキーが便利です！」です。
詳細
キーポリシーとは、キーに対する操作の権限を定義したものです。
デフォルトマスターキーの場合、ポリシーもAWSから提供され、ユーザは内容を変更できません。また、デフォルトマスターキーは、リージョンごと、サービスごと（RDS、S3、ELB、Redshiftなど）に1本だけ提供されます。たとえば、東京リージョンのS3バケットを暗号化するために利用できるデフォルトマスターキーは、1種類しかありません。当然、利用できるポリシーも1種類です。
一方、カスタマーマスターキーでは、ユーザが自由にポリシーを作成して適用できます。また、リージョンに複数作成できます。複数のポリシーを用途に応じて使い分けるには、カスタマーマスターキーが便利でしょう。
Q4. データキーは無効化できる？
「カスタマーマスターキーが有効化/無効化できるのは分かったけど、データキーは削除や無効化ができるのか？」という質問を同僚から受けました。
回答は「データキーを明示的に無効化するAPIは存在しません」です。
とはいえ、ユースケースとして、「作成済みの暗号化されたデータキーを、ある時点以降は復号に利用されたくない」という場合があるかもしれません。それには、次の対処法があります。
- ユーザが特定できる場合、そのユーザによるDecrypt操作をキーポリシーで禁止する
- ユーザが特定できない場合、マスターキーを無効化する
しかし、複数のサービスでマスターキーを共用していると、Q2で挙げたような制約が発生し、安易にキーを無効化できない状況に陥ることが考えられます。データキーの暗号化に使うマスターキーは、用途によって使い分けたほうがよいと思います。
おわりに
質問してくださった皆さん、ありがとうございました。不明点は解決しましたでしょうか？
他にもこういった話題が出てきましたら、また補遺をホイホイと書いていきたいと思います。ご質問、ツッコミ等、ぜひよろしくお願いいたします。
それでは、また。
